home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1048.txt < prev    next >
Text File  |  1994-08-01  |  15KB  |  395 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     P. Prindeville
  8. Request for Comments: 1048                             McGill University
  9.                                                            February 1988
  10.  
  11.  
  12.                   BOOTP Vendor Information Extensions
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This memo proposes an addition to the Bootstrap Protocol (BOOTP).
  18.    Comments and suggestions for improvements are sought.  Distribution
  19.    of this memo is unlimited.
  20.  
  21. Introduction
  22.  
  23.    As workstations and personal computers proliferate on the Internet,
  24.    the administrative complexity of maintaining a network is increased
  25.    by an order of magnitude.  The assignment of local network resources
  26.    to each client represents one such difficulty.  In most environments,
  27.    delegating such responsibility to the user is not plausible and,
  28.    indeed, the solution is to define the resources in uniform terms, and
  29.    to automate their assignment.
  30.  
  31.    The basic Bootstrap Protocol [RFC-951] dealt with the issue of
  32.    assigning an internet address to a client, as well as a few other
  33.    resources.  The protocol included provisions for vendor-defined
  34.    resource information.
  35.  
  36.    This memo defines a (potentially) vendor-independent interpretation
  37.    of this resource information.
  38.  
  39. Overview of BOOTP
  40.  
  41.    While the Reverse Address Resolution (RARP) Protocol [RFC-903] may be
  42.    used to assign an IP address to a local network hardware address, it
  43.    provides only part of the functionality needed.  Though this protocol
  44.    can be used in conjunction with other supplemental protocols (the
  45.    Resource Location Protocol [RFC-887], the Domain Name System [RFC-
  46.    883]), a more integrated solution may be desirable.
  47.  
  48.    Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that allows a
  49.    booting host to configure itself dynamically, and more significantly,
  50.    without user supervision.  It provides a means to assign a host its
  51.    IP address, a file from which to download a boot program from some
  52.    server, that server's address, and (if present) the address of an
  53.    Internet gateway.
  54.  
  55.  
  56.  
  57.  
  58. Prindeville                                                     [Page 1]
  59.  
  60. RFC 1048                    BOOTP Extensions               February 1988
  61.  
  62.  
  63.    One obvious advantage of this procedure is the centralized management
  64.    of network addresses, which eliminates the need for per-host unique
  65.    configuration files.  In an environment with several hundred hosts,
  66.    maintaining local configuration information and operating system
  67.    versions specific to each host might otherwise become chaotic.  By
  68.    categorizing hosts into classes and maintaining configuration
  69.    information and boot programs for each class, the complexity of this
  70.    chore may be reduced in magnitude.
  71.  
  72. BOOTP Vendor Information Format
  73.  
  74.    The full description of the BOOTP request/reply packet format may be
  75.    found in [RFC-951].  The rest of this document will concern itself
  76.    with the last field of the packet, a 64 octet area reserved for
  77.    vendor information, to be used in a hitherto unspecified fashion.  A
  78.    generalized use of this area for giving information useful to a wide
  79.    class of machines, operating systems, and configurations follows.  In
  80.    situations where a single BOOTP server is to be used among
  81.    heterogeneous clients in a single site, a generic class of data may
  82.    be used.
  83.  
  84.    Vendor Information "Magic Cookie"
  85.  
  86.       As suggested in [RFC-951], the first four bytes of this field have
  87.       been assigned to the magic cookie, which identifies the mode in
  88.       which the succeeding data is to be interpreted.  The value of the
  89.       magic cookie is the 4 octet dotted decimal 99.130.83.99 (or
  90.       hexadecimal number 63.82.53.63) in network byte order.
  91.  
  92.    Format of Individual Fields
  93.  
  94.       The vendor information field has been implemented as a free
  95.       format, with extendable tagged sub-fields.  These sub-fields are
  96.       length tagged (with exceptions; see below), allowing clients not
  97.       implementing certain types to correctly skip fields they cannot
  98.       interpret.  Lengths are exclusive of the tag and length octets;
  99.       all multi-byte quantities are in network byte-order.
  100.  
  101.       Fixed Length Data
  102.  
  103.          The fixed length data are comprised of two formats.  Those that
  104.          have no data consist of a single tag octet and are implicitly
  105.          of one-octet length, while those that contain data consist of
  106.          one tag octet, one length octet, and length octets of data.
  107.  
  108.          Pad Field (Tag: 0, Data: None)
  109.  
  110.             May be used to align subsequent fields to word boundaries
  111.  
  112.  
  113.  
  114. Prindeville                                                     [Page 2]
  115.  
  116. RFC 1048                    BOOTP Extensions               February 1988
  117.  
  118.  
  119.             required by the target machine (i.e., 32-bit quantities such
  120.             as IP addresses on 32-bit boundaries).
  121.  
  122.          Subnet Mask Field (Tag: 1, Data: 4 subnet mask bytes)
  123.  
  124.             Specifies the net and local subnet mask as per the standard
  125.             on subnetting [RFC-950].  For convenience, this field must
  126.             precede the GATEWAY field (below), if present.
  127.  
  128.          Time Offset Field (Tag: 2, Data: 4 time offset bytes)
  129.  
  130.             Specifies the time offset of the local subnet in seconds
  131.             from Coordinated Universal Time (UTC); signed 32-bit
  132.             integer.
  133.  
  134.          End Field (Tag: 255, Data: None)
  135.  
  136.             Specifies end of usable data in the vendor information area.
  137.             The rest of this field should be filled with PAD zero)
  138.             octets.
  139.  
  140.       Variable Length Data
  141.  
  142.          The variable length data has a single format; it consists of
  143.          one tag octet, one length octet, and length octets of data.
  144.  
  145.          Gateway Field (Tag: 3, Data: N address bytes)
  146.  
  147.             Specifies the IP addresses of N/4 gateways for this subnet.
  148.             If one of many gateways is preferred, that should be first.
  149.  
  150.          Time Server Field (Tag: 4, Data: N address bytes)
  151.  
  152.             Specifies the IP addresses of N/4 time servers [RFC-868].
  153.  
  154.          IEN-116 Name Server Field (Tag: 5, Data: N address bytes)
  155.  
  156.             Specifies the IP addresses of N/4 name servers [IEN-116].
  157.  
  158.          Domain Name Server Field (Tag: 6, Data: N address bytes)
  159.  
  160.             Specifies the IP addresses of N/4 domain name servers RFC-
  161.             883].
  162.  
  163.          Log Server Field (Tag: 7, Data: N address bytes)
  164.  
  165.             Specifies the IP addresses of N/4 MIT-LCS UDP log server
  166.             [LOGGING].
  167.  
  168.  
  169.  
  170. Prindeville                                                     [Page 3]
  171.  
  172. RFC 1048                    BOOTP Extensions               February 1988
  173.  
  174.  
  175.          Cookie/Quote Server Field (Tag: 8, Data: N address bytes)
  176.  
  177.             Specifies the IP addresses of N/4 Quote of the Day servers
  178.             [RFC-865].
  179.  
  180.          LPR Server Field (Tag: 9, Data: N address bytes)
  181.  
  182.             Specifies the IP addresses of N/4 Berkeley 4BSD printer
  183.             servers [LPD].
  184.  
  185.          Impress Server Field (Tag: 10, Data: N address bytes)
  186.  
  187.             Specifies the IP addresses of N/4 Impress network image
  188.             servers [IMAGEN].
  189.  
  190.          RLP Server Field (Tag: 11, Data: N address bytes)
  191.  
  192.             Specifies the IP addresses of N/4 Resource Location Protocol
  193.             (RLP) servers [RFC-887].
  194.  
  195.          Hostname (Tag: 12, Data: N bytes of hostname)
  196.  
  197.             Specifies the name of the client. The name may or may not
  198.             domain qualified: this is a site-specific issue.
  199.  
  200.          Reserved Fields (Tag: 128-254, Data: N bytes of undefined
  201.          content)
  202.  
  203.             Specifies additional site-specific information, to be
  204.             interpreted on an implementation-specific basis.  This
  205.             should follow all data with the preceding generic tags 0-
  206.             127).
  207.  
  208. Extensions
  209.  
  210.    Additional generic data fields may be registered by contacting:
  211.  
  212.           Joyce K. Reynolds
  213.           USC - Information Sciences Institute
  214.           4676 Admiralty Way
  215.           Marina del Rey, California  90292-6695
  216.  
  217.           or by E-mail as: JKREYNOLDS@ISI.EDU
  218.           (nic handle JKR1).
  219.  
  220.    Implementation specific use of undefined generic types (those in the
  221.    range 12-127) may conflict with other implementations, and
  222.    registration is required.
  223.  
  224.  
  225.  
  226. Prindeville                                                     [Page 4]
  227.  
  228. RFC 1048                    BOOTP Extensions               February 1988
  229.  
  230.  
  231.    When selecting information to put into the vendor specific area, care
  232.    should be taken to not exceed the 64 byte length restriction.
  233.    Nonessential information (such as host name and quote of the day
  234.    server) may be excluded, which may later be located with a more
  235.    appropriate service protocol, such as RLP or the WKS resource-type of
  236.    the domain name system.  Indeed, even RLP servers may be discovered
  237.    using a broadcast request to locate a local RLP server.
  238.  
  239. Comparison to Alternative Approaches
  240.  
  241.    Extending BOOTP to provide more configuration information than the
  242.    minimum required by boot PROMs may not be necessary.  Rather than
  243.    having each module in a host (e.g., the time module, the print
  244.    spooler, the domain name resolver) broadcast to the BOOTP server to
  245.    obtain the addresses of required servers, it would be better for each
  246.    of them to multicast directly to the particular server group of
  247.    interest, possibly using "expanding ring" multicasts.
  248.  
  249.    The multicast approach has the following advantages over the BOOTP
  250.    approach:
  251.  
  252.     - It eliminates dependency on a third party (the BOOTP server) that
  253.     may be temporarily unavailable or whose database may be incorrect or
  254.     incomplete.  Multicasting directly to the desired services will
  255.     locate those servers that are currently available, and only those.
  256.  
  257.     - It reduces the administrative chore of keeping the (probably
  258.     replicated) BOOTP database up-to-date and consistent.  This is
  259.     especially important in an environment with a growing number of
  260.     services and an evolving population of servers.
  261.  
  262.     - In some cases, it reduces the amount of packet traffic and/or the
  263.     delay required to get the desired information.  For example, the
  264.     current time can be obtained by a single multicast to a time server
  265.     group which evokes replies from those time servers that are
  266.     currently up.  The BOOTP approach would require a broadcast to the
  267.     BOOTP server, a reply from the BOOTP server, one or more unicasts to
  268.     time servers (perhaps waiting for long timeouts if the initially
  269.     chosen server(s) are down), and finally a reply from a server.
  270.  
  271.    One apparent advantage of the proposed BOOTP extensions is that they
  272.    provide a uniform way to locate servers.  However, the multicast
  273.    approach could also be implemented in a consistent way across
  274.    multiple services.  The V System naming protocol is a good example of
  275.    this; character string pathnames are used to name any number of
  276.    resources (i.e., not just files) and a standard subroutine library
  277.    looks after multicasting to locate the resources, caching the
  278.    discovered locations, and detecting stale cache data.
  279.  
  280.  
  281.  
  282. Prindeville                                                     [Page 5]
  283.  
  284. RFC 1048                    BOOTP Extensions               February 1988
  285.  
  286.  
  287.    Another apparent advantage of the BOOTP approach is that it allows an
  288.    administrator to easily control which hosts use which servers.  The
  289.    multicast approach favors more distributed control over resource
  290.    allocation, where each server decides which hosts it will serve,
  291.    using whatever level of authentication is appropriate for the
  292.    particular service.  For example, time servers usually don't care who
  293.    they serve (i.e., administrative control via the BOOTP database is
  294.    unnecessary), whereas file servers usually require strong
  295.    authentication (i.e., administrative control via the BOOTP database
  296.    is insufficient).
  297.  
  298.    The main drawback of the multicast approach, of course, is that IP
  299.    multicasting is not widely implemented, and there is a need to locate
  300.    existing services which do not understand IP multicasts.
  301.  
  302.    The BOOTP approach may be most efficient in the case that all the
  303.    information needed by the client host is returned by a single BOOTP
  304.    reply and each program module simply reads the information it needs
  305.    from a local table filled in by the BOOTP reply.
  306.  
  307. Acknowledgments
  308.  
  309.    I would like to thank the following persons for their helpful
  310.    comments and insights into this memo: Drew Perkins, of Carnagie
  311.    Mellon University, Bill Croft, of Stanford University, and co-author
  312.    of BOOTP, and Steve Deering, also of Stanford University, for
  313.    contributing the "Comparison to Alternative Approaches" section.
  314.  
  315. References
  316.  
  317.    [RFC-951]   Croft, B., and J. Gilmore, "Bootstrap Protocol", Network
  318.                Information Center, SRI International, Menlo Park,
  319.                California, September 1985.
  320.  
  321.    [RFC-903]   Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A
  322.                Reverse Address Resolution Protocol", Network Information
  323.                Center, SRI International, Menlo Park, California, June
  324.                1984.
  325.  
  326.    [RFC-887]   Accetta, M., "Resource Location Protocol", Network
  327.                Information Center, SRI International, Menlo Park,
  328.                California, December 1983.
  329.  
  330.    [RFC-883]   Mockapetris, P., "Domain Name - Implementation and
  331.                Specification", Network Information Center, SRI
  332.                International, Menlo Park, California, November 1983.
  333.  
  334.    [RFC-950]   Mogul, J., "Internet Standard Subnetting Procedure",
  335.  
  336.  
  337.  
  338. Prindeville                                                     [Page 6]
  339.  
  340. RFC 1048                    BOOTP Extensions               February 1988
  341.  
  342.  
  343.                Network Information Center, SRI International, Menlo
  344.                Park, California, August 1985.
  345.  
  346.    [RFC-868]   Postel, J., "Time Protocol", Network Information Center,
  347.                SRI International, Menlo Park, California, May 1983.
  348.  
  349.    [IEN-116]   Postel, J., "Internet Name Server", Network Information
  350.                Center, SRI International, Menlo Park, California, August
  351.                1979.
  352.  
  353.    [LOGGING]   Clark, D., Logging and Status Protocol", Massachusetts
  354.                Institute of Technology Laboratory for Computer Science,
  355.                Cambridge, Massachusetts, 1981.
  356.  
  357.    [RFC-865]   Postel, J., "Quote of the Day Protocol", Network
  358.                Information Center, SRI International, Menlo Park,
  359.                California, May 1983.
  360.  
  361.    [LPD]       Campbell, R., "4.2BSD Line Printer Spooler Manual", UNIX
  362.                Programmer's Manual, Vol II,  University of California at
  363.                Berkeley, Computer Science Division, July 1983.
  364.  
  365.    [IMAGEN]    "Image Server XT Programmer's Guide", Imagen Corporation,
  366.                Santa Clara, California, August 1986.
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Prindeville                                                     [Page 7]
  395.